Content is retrieved from the DNS with little more than a transaction ID and source port guaranteeing on-path visibility. Generally, only web browsers validate public keys; anything that is not a browser either trusts whatever public key they see—SSL (Secure Sockets Layer), a protocol for encrypting information over the Internet, or trusts the first key seen and remembers it for future use—SSH (Secure Shell), a cryptographic network protocol for secure data communication via a secure channel over an insecure network. In the latter case, administrators are warned that keys change, but key change events are common enough that they can be relied upon to accept the new key.
DNSSEC (which guarantees secure transmission) already exist, but the operational load of running it tends to be severe due to limitations of the offline key signing. While being able to precalculate signatures was critical for the DNS roots, online key signing is much more flexible to the real world of geolocation and load balancing and other aspects of DNS. Online key signing is also much more capable of dealing with proxied delegation, i.e. when a secure server is in front of a server that has not yet upgraded to DNSSEC, online key signing allows the secure server to sign for records behind it rather than merely declaring that some portion of the DNSSEC namespace is unsigned. Thus, existing deployment models are aligned around the need for incremental opt-in at the root and Top Level Domain (TLD) (i.e., not everything under com can be signed) instead of the desire for incrementally correct 100% coverage (e.g., everything under bankofamerica.com should be signed, the issue becomes generating those signatures as close to the appropriate departments as is feasible).
In general, there is a small amount of DNSSEC support in any browser (e.g., Chrome supports DNSSEC signatures stapled into SSL certificates) but very little to no other client code has any serious support. This invention overcomes this limitation.